Иногда интересно в целях аудита посмотреть, какие команды были выполнены на хосте VMware ESXi 5.0, а что интереснее - кто именно их выполнял. Для этого на хосте ESXi есть специальный лог-файл, хранящий введенные команды:

/var/log/shell.log

В этот лог на хосте можно также заглянуть и через веб-браузер по адресу: https://ESXiHostnameOrIP/host/shell.log

Посмотрим его содержимое:

Отлично - историю команд мы получили, но кто из пользователей их выполнял? Для этого нам понадобится запомнить число в квадратных скобках после слова "shell" - это так называемый World ID для сессии (например, 2938482). Обратите также внимание на присутствующий для каждой команды timestamp.

Далее нам понадобиться открыть следующий лог-файл, хранящий данные об аутентификации пользователей:

/var/log/auth.log

В этот лог на хосте можно также заглянуть и через веб-браузер по адресу: https://ESXiHostnameOrIP/host/auth.log

Там мы найдем такие строчки, если использовался прямой логин в ESXi Shell:

2011-08-29T18:01:00Z login[2938482]: root login on 'char/tty/1'

Если использовался логин по SSH в интерактивном режиме, мы увидим вот такое:

2011-08-29T18:01:00Z sshd[12345]: Connection from 10.11.12.13 port 2605
2011-08-29T18:01:00Z sshd[12345]: Accepted keyboard-interactive/pam for root from10.11.12.13 port 2605 ssh2
2011-08-29T18:01:00Z sshd[2938482]: Session opened for 'root' on /dev/char/pty/t0
2011-08-29T18:01:00Z sshd[12345]: Session closed for 'root' on /dev/char/pty/t0
...
2011-08-29T18:35:05Z sshd[12345]: Session closed for 'root' 2

Если использовался логин по SSH с использованием публичного ключа, то мы увидим следующее:

2011-08-29T18:01:00Z sshd[12345]: Connection from 10.11.12.13 port 2605
2011-08-29T18:01:00Z sshd[12345]: Accepted publickey for root from 10.11.12.13 port 2605ssh2
2011-08-29T18:01:00Z sshd[2938482]: Session opened for 'root' on /dev/char/pty/t0
2011-08-29T18:01:00Z sshd[12345]: Session closed for 'root' on /dev/char/pty/t0
...
2011-08-29T18:35:05Z sshd[12345]: Session closed for 'root' 2

Теперь, я думаю понятно, что World ID сессии, который мы нашли для пользователя открывшего сессию с ESXi Shell и который указан в квадратных скобках строчек лога auth.log - тот же самый, что и в логе shell.log. Таким образом, в логе shell можно всегда понимать, кто и когда выполнял данные команды, зная World ID сессии пользователя из auth.log и timestamp.

Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:

APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:

2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...

Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:

Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.

В этом случае надо искать проблему в фабрике SAN или на массиве.

PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.

А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:

В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.

Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):

В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:

2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry

Ключевое слово здесь - permanently.

Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.

Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:

disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.

das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.

Рекомендуется, чтобы обе эти настройки были включены.

Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".

Не все знают, что в качестве распределенного коммутатора с расширенной функциональностью для инфраструктуры VMware vSphere существует не только устройство Cisco Nexus 1000V. Есть также и виртуальное устройство от IBM, которое называется System Networking Distributed Switch 5000V (DVS 5000V).

Это тоже программный распределенный коммутатор, который поставляется в виде 2 компонентов:

• Host Module (он же Data Path Module, DPM) - модуль, поставляемый в zip-формате (Offline Bundle) для хостов VMware ESXi 5.x, позволяющий контролировать состояние виртуальных коммутаторов в пределах хоста.
• Controller - виртуальный модуль (Virtual Appliance) в формате OVA, позволяющий централизованно управлять сетевой инфраструктурой виртуализации через хостовые модули.

vDS от IBM так же, как и Nexus 1000V, интегрирован с VMware vCenter и отображается как обычный Distributed Virtual Switch в интерфейсе vSphere Client. При этом он обладает следующими расширенными возможностями:

• Поддержка технологии Private VLAN для разделения трафика ВМ
• Поддержка списков контроля доступа (ACL) для контроля трафика ВМ
• Поддержка технологий зеркалирования портов (Port Mirroring): локально (SPAN) и удаленной (ERSPAN)
• Поддержка техники мониторинга трафика sFlow (похожа на NetFlow)
• Управление трафиком и статистика на базе стандарта IEEE 802.1Qbg (Edge Virtual Bridging, EVB)
• Поддержка технологий Static Port Aggregation и Dynamic Port Aggregation
• Поддержка логирования Syslog и по SNMP

С точки зрения управления таким распределенным коммутатором DVS 5000V оно построено на базе операционной системы IBM NOS (Network Operating System) и предоставляет следующие интерфейсы:

• Telnet
• SSH
• SNMP
• TACACS+
• RADIUS
• Интерфейс командной строки (CLI)

Более подробно о виртуальном модуле IBM DVS 5000V можно прочитать в даташите, а также в руководстве пользователя.

Мы уже писали о новых возможностях VMware View 5.1 и, в частности, о технологии Storage Accelerator, которая использует кэш CBRC на чтение на стороне хоста VMware ESXi, чтобы быстрее отдавать блоки виртуальной машине напрямую из памяти, не обращаясь к хранилищу.

Как понятно из названия (Content Based Read Cache), технология Storage Accelerator позволяет оптимизировать ввод-вывод именно тогда, когда в среде виртуальных ПК у нас много операций чтения, которые происходят для множества связанных клонов, развертываемых из реплики View Compser. Таких показательных ситуаций две: Boot Storm (когда пользователи приходят на работу и одновременно включают свои ПК для доступа к своим виртуальным машинам) и Antivirus Storm (когда антивирус начинает шерстить файлы в гостевой ОС).

Интересные картинки по тестированию данной технологии обнаружились в одном из тестов Login VSI, которая проверила, как это работает на хосте со 143-мя связанными клонами виртуальных ПК для размера кэша CBRC размером в 2 ГБ. Работает это замечательно:

Как мы видим, к сотой минуте нагрузка улеглась и операции чтения стали уже не такими однородными. Для постоянных (persistent) дисков (т.е. тех, которые не развертываются из единого базового образа) технология CBRC тоже дает свои плоды:

Ну и здорово помогает нам View Storage Accelerator при антивирусном шторме, когда антивирусники большого количества виртуальных машин одновременно набрасываются на файлы гостевых ОС:

Ну и под конец напомним, что в качестве антивирусных решений в VDI-средах для оптимизации нагрузки нужно использовать решения с поддержкой VMsafe.

Для обладателей устройств iPad или iPhone и, по совместительству, разработчиков сценариев для автоматизации операций в виртуальной инфраструктуре VMware vSphere на App Store есть замечательное справочное руководство по скриптам PowerCLI - vPowerCLI5 Reference.

Справочник включает в себя более 200 командлетов PowerCLI, которые упорядочены в алфавитном порядке, также есть поиск. Для каждого командлета предоставляется описание, взятое из vSphere PowerCLI Reference от VMware.

Обращаем также внимание на плакаты PowerCLI для ESXi Image Builder и Auto Deploy в формате PDF.

Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.

Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:

• Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
• Перегрузка очереди ввода-вывода со стороны хост-сервера.
• Достижение предела полосы пропускания между хостом и хранилищем.
• Высокая загрузка CPU хост-сервера.
• Проблемы с драйверами хранилищ на уровне гостевой ОС.
• Некорректно настроенные приложения.

Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.

Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:

• Размер запроса ввода-вывода (I/O Size)
• Процент обращений на чтение (Read)
• Процент случайных обращений (Random)

Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:

8KB I/O size, 80% Random, 80% Read

Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).

Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:

Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.

Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.

Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.

Вчера мы написали о новых возможностях Veeam Backup and Replication 6.1, которая вчера же стала доступна для загрузки. Новая версия продукта номер 1 имеет множество новых возможностей, и, помимо этого, включает бесплатное издание Veeam Backup Free Edition.

В таблице ниже приведены основные отличия коммерческой Veeam Backup and Replication и бесплатной Veeam Backup (обратите внимание, что в бесплатной версии слова Replication нет). Бесплатное издание построено на ядре знаменитой утилиты Veeam FastSCP, которой пользовались десятки тысяч администраторов для загрузки файлов на ESX / ESXi серверы. Теперь программисты Veeam привели ее в порядок, обновили механизмы работы через vSphere API, добавили некоторую функциональность от коммерческого Veeam B&R (например, VeeamZIP) и бесплатно отдают пользователям.

Посмотрим, что нам предлагают просто так:

Отметим, что вся функциональность Veeam Backup and Replication Standard полностью включена в издание Enterprise Edition, у которого значительно больше возможностей.

В итоге, в форме Veeam Backup Free Edition мы получили больше функций, чем в Veeam FastSCP, за что спасибо разработчикам. Важный момент: обновление с бесплатной версии Veeam Backup Free Edition до полноценного Veeam Backup and Replication происходит просто вводом лицензионного ключа, без необходимости переустановки продукта.

Бесплатный Veeam Backup Free можно скачать по этой ссылке: http://www.veeam.com/virtual-machine-backup-solution-free/download.html.

Коммерческий Veeam Backup and Replication можно скачать тут: http://www.veeam.com/vmware-esx-backup/download.html.

Компания VMware, после недавней публикации черновика своего руководства по обеспечению безопасности VMware vSphere 5, объявила о выпуске окончательной версии документа VMware vSphere 5 Security Hardening Guide. Теперь это руководство выпускается в виде xlsx-табличек, что хотя и выглядит как-то несолидно, однако удобнее для проектных команд при работе с документом (они все равно это вбивают в Excel):

Потенциальные угрозы, традиционно, поделены на 4 категории:

• Виртуальные машины (настройки, устройства, интерфейсы, VMware Tools)
• Хосты VMware ESXi (доступ к управлению, логи, хранилища)
• Сетевое взаимодействие (включая распределенный коммутатор dvSwitch)
• Сервер управления vCenter (доступ к управляющим компонентам и т.п.)

Также обратим внимание на документ "vSphere Hardening Guide: 4.1 and 5.0 comparison", отражающий основные отличия руководства для версий 4.1 и 5.0 (сделан он был еще для драфта Hardening'а версии 5.0).

В отличие от предыдущей версии документа, где были приведены уровни применения рекомендаций ИБ (Enterprise, SMB и т.п.), теперь используются "профили" инфраструктур:

• Profile 3 - рекомендации и настройки, которых следует придерживаться во всех инфраструктурах.
• Profile 2 - то, что необходимо делать в окружениях, где обрабатываются чувствительные данные (например, коммерческая тайна).
• Profile 1 - самый высокий уровень рекомендаций, например, для организаций, работающих с гостайной.

Еще одна полезная вещь - в столбцах для некоторых рекомендаций, касающихся конкретных конфигураций хостов ESXi или виртуальных машин, приведены ссылки на статьи KB или непосредственно сами команды для осуществления настройки по следующим интерфейсам: vSphere API, vSphere CLI (vCLI), ESXi Shell (DCUI или SSH), PowerCLI.

Приведены также и конкретные команды, которые позволяют узнать, в каком состоянии находится у вас на хосте та или иная настройка (assessment):

Скачать финальную версию VMware vSphere 5 Security Hardening Guide можно по этой ссылке.

Напомним также, что совсем недавно в продажу поступил продукт vGate R2 от компании Код Безопасности, который позволяет автоматически сканировать инфраструктуру vSphere 5 на предмет соответствия настройкам безопасности (и не только из этого документа), а также настраивать хост-серверы в соответствии с необходимыми и заданными политиками рекомендациями. Более подробно об этом написано тут.

P.S. Документ подготовлен в 10-м офисе, поэтому в более ранних версиях Microsoft Office у вас в некоторых ячейках могут отображаться значки решетки для ячеек, где много текста - ##### (то же самое будет и при печати). В этом случае нужно просто сменить формат ячейки на "Общий".

Мы уже писали об основных приемах по решению проблем на хостах VMware ESX / ESXi с помощью утилиты esxtop, позволяющей отслеживать все аспекты производительности серверов и виртуальных машин. Через интерфейс RCLI можно удаленно получать эти же данные с помощью команды resxtop.

Сегодня мы приведем простое объяснение иерархии счетчиков esxtop, касающихся хранилищ серверов VMware vSphere. Для того, чтобы взглянуть на основные счетчики esxtop для хранилищ, нужно запустить утилиту и нажать кнопку <d> для перехода в режим отслеживания показателей конкретных виртуальных машин (кликабельно). Данные значения будут представлены в миллисекундах (ms):

Если мы посмотрим на колонки, которые выделены красным прямоугольником, то в виде иерархии их структуру можно представить следующим образом:

Распишем их назначение:

• GAVG (Guest Average Latency) - общая задержка при выполнении SCSI-команд от гостевой ОС до хранилища сквозь все уровни работы машины с блоками данных. Это, само собой, самое большое значение, равное KAVG+DAVG.
• KAVG (Kernel Average Latency) - это задержка, возникающая в стеке vSphere для работы с хранилищами (гипервизор, модули для работы SCSI). Это обычно небольшое значение, т.к. ESXi имеет множество оптимизаций в этих компонентах для скорейшего прохождения команд ввода-вывода сквозь них.
• QAVG (Queue Average latency) - время, проведенное SCSI-командой в очереди на уровне стека работы с хранилищами, до передачи этой команды HBA-адаптеру.
• DAVG (Device Average Latency) - задержка прохождения команд от HBA адаптера до физических блоков данных на дисковых устройствах.

В блоге VMware, где разобраны эти показатели, приведены параметры для типичной нагрузки по вводу-выводу (8k I/O size, 80% Random, 80% Read). Для такой нагрузки показатель Latency (GAVG) 20-30 миллисекунд и более может свидетельствовать о наличии проблем с производительностью подсистемы хранения на каком-то из подуровней.

Как мы уже отметили, показатель KAVG, в идеале, должен быть равен 0 или исчисляться сотыми долями миллисекунды. Если он стабильно находится в пределах 2-3 мс или больше - тут уже можно подозревать проблемы. В этом случае нужно проверить значение столбца QUED для ВМ - если оно достигло 1 (очередь использована), то, возможно, выставлена слишком маленькая величина очереди на HBA-адаптере, и необходимо ее увеличить.

Для просмотра очереди на HBA-адаптере нужно переключиться в представление HBA кнопкой <u>:

Ну и если у вас наблюдается большое значение DAVG, то дело, скорее всего, не в хосте ESX, а в SAN-фабрике или дисковом массиве, на уровне которых возникают большие задержки.

Мы уже писали о  полезных нововведениях, касающихся сетевого взаимодействия, доступных в распределенном коммутаторе VMware vSphere Distributed Switch (vDS), которые облегчают жизнь сетевым администраторам. В частности, рассмотрели механизм Netflow и его поддержку в vSphere 5.

Напомним, что посредством vDS доступны следующие новые возможности, которые описаны в документе "What's New in VMware vSphere 5.0 Networking":

• Поддержка Netflow версии 5 - возможность просмотра трафика между виртуальными машинами (ВМ-ВМ на одном или разных хостах, а также ВМ-физический сервер) посредством сторонних продуктов, поддерживающих Netflow.
• Поддержка зеркалирования портов Switch Port Analyzer (аналог технологии SPAN в коммутаторах Cisco) - возможность дублировать трафик виртуальной машины (а также VMkernel и физических адаптеров) на целевую машину (Port Mirroring), которая может реализовывать функционал системы обнаружения или предотвращения вторжений (IDS/IPS).
• Поддержка открытого стандарта Link Layer Discovery Protocol (LLDP, в реализации 802.1AB) - это механизм обнаружения соседних сетевых устройств и сбора информации о них для решения различных проблем сетевыми администраторами. Ранее поддерживался только протокол CDP (Cisco Discovery Protocol), поддержка которого есть не во всех устройствах.
• Улучшения механизма Network I/O Control - пулы ресурсов для сетевого трафика и поддержка стандарта 802.1q. Опредлеямые пользователем пулы для различных типов трафика позволяют приоритезировать и ограничивать пропускную способность канала для них посредством механизма shares и limits.

Сегодня мы рассмотрим поддержку открытого стандарта Link Layer Discovery Protocol (LLDP) (то есть, вендоронезависимого), который позволяет обнаруживать соседние с серверами ESXi коммутаторы и собирать о них информацию для последующего анализа.

Ранее можно было использовать только протокол CDP (Cisco Discovery Protocol), что сужало применение данной возможности. Теперь в настройках vDS у нас есть выбор LLDP или CDP:

По умолчанию, при создании распределенного коммутатора vDS, включен протокол CDP, поэтому для включения LLDP его надо переопределить в настройках. В поле Operation есть три режима работы:

• Listen - ESXi обнаруживают и отображают информацию о непосредственно подключенном физическом коммутаторе, но информация о самом vDS не предоставляется администратору физического коммутатора.
• Advertise - ESXi, наоборот, рассказывают о vDS физическому коммутатору, но не собирают информацию о нем.
• Both - обе предыдущих опции: vDS и физический коммутатор получают информацию друг о друге.

Чтобы посмотреть статистику, собранную с помощью LLDP, нужно нажать на синюю иконку с информацией для выбранного dvSwitch:

Эта информация позволяет проследить физическую коммутацию кабелей с хоста ESXi на порты физического коммутатора, без необходимости идти в серверную и смотреть, как там все подключено.

Источник: http://rickardnobel.se/archives/644.

Иногда для целей тестирования какой-нибудь из технологий высокой доступности VMware (например, Fault Tolerance или HA) хочется сделать что-нибудь плохое с хост-сервером ESXi, чтобы посмотреть, как он эту ситуацию обработает. Самый простой вариант - это перезагрузить хост, ну а можно еще вывести его в искусственный PSOD (Purple Screen of Death) - по аналогии с синим экраном смерти в Windows. При этом будет создан также Kernel Dump, который вы можете поизучать.

Вызвать ситуацию Kernel Panic и PSOD на хосте ESXi можно простой командой, зайдя на него по SSH или в DCUI:

# vsish -e set /reliability/crashMe/Panic 1

Результат:

После перезагрузки хоста с ним все будет нормально.

С 21 по 24 мая проводилась конференция EMC World 2012, где одной из главных тем были, конечно же, решения по защите данных и балансировки нагрузки между географически распределенными датацентрами. Прежде всего были анонсированы решения EMC VPLEX 5.1 и RecoverPoint 3.5:

По-прежнему, SRA-адаптера для совместного решения VMware SRM+VPLEX до сих пор нет, потому как, похоже, нет окончательной ясности, нужен ли SRM, когда есть VPLEX Metro с синхронизированными томами между датацентрами и "растянутый кластер" VMware vMSC (vSphere Metro Storage Cluster) между хостами датацентров. Безусловно, сотрудники EMC говорят, что решения взаимодополняющие (т.к. SRM - это план восстановления после сбоев, а не схема катастрофоустойчивости), но пока SRM предлагается использовать только в схеме с решением для защиты данных EMC RecoverPoint, для которого SRA-адаптер уже есть:

На эту тему появился отдельный документ "Improving VMware Disaster Recovery with EMC RecoverPoint".

Появилась также поддержка разнесенных active/active кластеров Oracle RAC в EMC VPLEX:

С точки зрения vSphere Metro Storage Cluster также появилась пара интересных новостей. Во-первых, документ "VMware vSphere Metro Storage Cluster Case Study", описываещий различные сценарии отказов в растянутом кластере высокой доступности (vMSC), построенном между двумя географически разнесенными площадками:

Также напомним про документ "Stretched Clusters and VMware vCenter Site Recovery Manager", который поможет понять, в каких ситуациях пригодится растянутый кластер, а когда без SRM не обойтись.

Во-вторых, к программе сертификации  vSphere Metro Storage Cluster program присоединилась HP Lefthand:

Более подробно об этом можно прочитать в KB 2020097 или в документе "Implementing VMware vSphere Metro Storage Cluster with HP LeftHand Multi-Site storage". В HCL компании VMware решение HP Lefthand появилось в категории "iSCSI vSphere Metro Cluster Storage".

Ну и для тех, кому интересно, о чем еще говорили на EMC World, можно почитать тут и тут.

В последнее время становится все больше и больше компаний, предоставляющих сервисы аренды виртуальных машин в облачной инфраструктуре на платформе VMware vSphere. Между тем, защищенности таких инфраструктур и их соответствию стандартам безопасности (особенно российским), как правило, уделяется мало внимания. Сегодня мы поговорим о том, что можно сделать с помощью продукта vGate R2 для защиты виртуальных сред в датацентрах провайдеров, предоставляющих виртуальные машины VMware в аренду.

Как известно, в VMware vSphere 5 появилось несколько полезных нововведений, касающихся сетевого взаимодействия, доступных в распределенном коммутаторе VMware vSphere Distributed Switch (vDS), которые облегчают жизнь сетевым администраторам. В частности, посредством dvSwitch доступны следующие новые возможности, которые описаны в документе "What's New in VMware vSphere 5.0 Networking":

• Поддержка Netflow версии 5 - возможность просмотра трафика между виртуальными машинами (ВМ-ВМ на одном или разных хостах, а также ВМ-физический сервер) посредством сторонних продуктов, поддерживающих Netflow.
• Поддержка зеркалирования портов Switch Port Analyzer (аналог технологии SPAN в коммутаторах Cisco) - возможность дублировать трафик виртуальной машины (а также VMkernel и физических адаптеров) на целевую машину (Port Mirroring), которая может реализовывать функционал системы обнаружения или предотвращения вторжений (IDS/IPS).
• Поддержка открытого стандарта Link Layer Discovery Protocol (LLDP, в реализации 802.1AB) - это механизм обнаружения соседних сетевых устройств и сбора информации о них для решения различных проблем сетевыми администраторами. Ранее поддерживался только протокол CDP (Cisco Discovery Protocol), поддержка которого есть не во всех устройствах.
• Улучшения механизма Network I/O Control - пулы ресурсов для сетевого трафика и поддержка стандарта 802.1q. Опредлеямые пользователем пулы для различных типов трафика позволяют приоритезировать и ограничивать пропускную способность канала для них посредством механизма shares и limits.

Все эти новые возможности мы разберем в следующих заметках, а сегодня сосредоточимся на механизме Netflow и его поддержке в vSphere 5. NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами.

Для сбора информации о трафике по протоколу NetFlow требуются следующие компоненты:

• Сенсор. Собирает статистику по проходящему через него трафику. Обычно это L3-коммутатор или маршрутизатор, хотя можно использовать и отдельно стоящие сенсоры, получающие данные путем зеркалирования порта коммутатора. В нашем случае это распределенный коммутатор vDS.
• Коллектор. Собирает получаемые от сенсора данные и помещает их в хранилище.
• Анализатор. Анализирует собранные коллектором данные и формирует пригодные для чтения человеком отчёты (часто в виде графиков).

NetFlow дает возможность сетевому администратору мониторить сетевые взаимодействия виртуальных машин для дальнейших действий по обнаружению сетевых вторжений, отслеживания соответствия конфигураций сетевых служб и анализа в целом. Кроме того, данная возможность полезна тогда, когда требуется отслеживать поток трафика от приложений внутри виртуальной машины с целью контроля производительности сети и целевого использования трафика.

Синяя линия на картинке показывает настроенный виртуальный коммутатор, который посылает данные Netflow на стороннюю машину (коллектор), которая подключена к хост-серверу VMware ESXi через физический коммутатор. Коллектор уже передает данные анализатору. Netflow может быть включен на уровне отдельной группы портов (dvPortGroup), отдельного порта или аплинка (Uplink).

Для начала настройки Netflow нужно зайти в свойства коммутатора vDS (он должен быть версии 5.0.0 или выше):

Здесь мы указываем IP-адрес коллектора, куда будут отправляться данные, его порт, а также единый IP-адрес коммутатора vDS, чтобы хосты не представлялись отдельными коммутаторами для коллектора.

Включить мониторинг Netflow можно в свойствах группы портов на vDS в разделе Monitoring:

Далее в эту группу портов включаем одну из виртуальных машин:

Теперь можно использовать один из продуктов для сбора и анализа трафика Netflow, например, Manage Engine Netflow Analyzer. Пример статистики, которую собирает этот продукт по протоколам (в данном случае большинство трафика - http):

Netflow можно использовать для различных целей мониторинга, например, в инфраструктуре VMware View, где присутствуют сотни виртуальных машин, можно сгруппировать трафик по группам и смотреть, сколько трафика выжирается видеосервисами (Youtube, к примеру), так как это может сильно влиять на производительность сети в целом:

Применений Neflow на самом деле уйма, поэтому его поддержка в VMware vSphere 5 может оказаться вам очень полезной.

На проходящих сейчас по всему миру мероприятиях VMware Partner Exchange On Tour (PEX) сотрудники VMware все больше рассказывают о возможностях новой версии платформы виртуализации серверов VMware vSphere 5.1. Во-первых, стало известно, что vSphere 5.1 будет анонсирована на предстоящем VMworld, который пройдет в Сан-Франциско с 27 по 30 августа этого года.

Во-вторых, во всяких твиттерах появилось описание некоторых новых возможностей VMware vSphere 5.1, которые мы увидим осенью этого года, а именно:

• Поддержка технологии кластеров непрерывной доступности Fault Tolerance для виртуальных машин с несколькими виртуальными процессорами (vCPU).
• Загрузка хостов через адаптеры Fiber Channel over Ethernet (FCoE).
• Поддержка виртуализованных контроллеров домена Active Directory. Windows Server 8, который исполняется в виртуальной машине, на самом деле в курсе, что он работает в ВМ. Это означает, что создание и удаление снапшота такой машины не приведет к проблемам с AD, возникающих с номером последовательного обновления (Update Sequence Number, USN) контроллера. Ранее при восстановлении из снапшота из-за проблем с USN могла остановиться репликация данных каталога. Теперь Microsoft добавила технологию Generation ID, которая позволяет виртуальному контроллеру домена знать, последняя ли версия каталога им используется. За счет этого решаются проблемы с репликацией при откате к снапшоту, а также появляется возможность клонирования виртуальных машин с контроллерами домена. Соответственно, такую возможность и будет поддерживать vSphere 5.1.

Что касается технологии Fault Tolerance для ВМ с несколькими vCPU, то, как пишут наши коллеги на vMind.ru, эта технология будет требовать соединения 10 GigE для работы механизма "SMP Protocol", который придет на смену технологии vLockstep. При этом работать она сможет вообще без общего хранилища для виртуальных машин, которые могут быть разнесены по разным датасторам и хостам:

Безусловно, это не все новые возможности, которые следует ожидать в VMware vSphere 5.1, поэтому мы будем держать вас в курсе новых подробностей по мере их поступления.

Если вы являетесь разработчиком и администраторов скриптов PowerCLI / PowerShell для автоматизации операций в виртуальной инфраструктуре VMware vSphere, вам, наверняка, часто приходится хардкодить логин и пароль для соединения с сервером vCenter или вводить их в интерактивном режиме. Это не очень безопасно (мало ли кто увидит ваш скрипт на экране), да и вообще, не очень удобно.

Специально для этого в PowerCLI есть хранилище, называемое Credential Store, в которое можно помещать логин и пароль от сервера, с которым вы соединяетесь из скрипта.

Делается это следующим командлетом:

New-VICredentialStoreItem -Host 192.168.1.10 -User 'user' -Password 'password'

Таким образом для этого хоста вы помещаете креды "user" с паролем "password" в шифрованное хранилище Credential Store, которое находится в следующем файле:

%APPDATA%\VMware\credstore\vicredentials.xml

Теперь при соединении с vCenter из скрипта, просто пишете:

Connect-VIServer 192.168.1.10

В этом случае, при отсутствии указания логина и пароля, PowerCLI заглядывает в хранилище и смотрит, нет ли там кредов для этого хоста, и если они есть, то подставляет их. Все просто.

Чтобы посмотреть креды из хранилища, нужно просто вызвать следующий командлет:

Get-VICredentialStoreItem -User 'user' -Host 192.168.1.10 -File 'credentials.xml'

Ну а для удаления кредов пишем вот так (для удаления всех логинов и паролей от хоста):

Remove-VICredentialStoreItem -Host 192.168.1.10 -Confirm

Или так для удаления кредов указанного пользователя в подсети хостов:

Remove-VICredentialStoreItem -User 'admin' -Host '192.168.*' -File 'credentials.xml' -Confirm

Такой способ хранения логинов и паролей для скриптов действует для конкретного пользователя, так как они хранятся в Credential Store в зашифрованном виде и могут быть расшифрованы только под ним. То есть, если злоумышленник украдет виртуальную машину с этими скриптами, но не сможет залогиниться под этим пользователем, получить эти пароли он не сможет, при условии использования Windows file encryption (EFS) для файла хранилища.

Есть также и альтернативный метод хранения кредов для скриптов в произвольном файле.

Интересная штука обнаружилась среди средств управления и мониторинга инфраструктуры VMware vSphere - Cloud Resource Meter от компании 6fusion, которая специализируется на утилитах для облачных сред. Это такая штука, которая реализована в виде виртуального модуля (Virtual Appliance), позволяющая оценить облачную инфраструктуру vSphere "в попугаях", то есть в специальных единицах Workload Allocation Cube (WAC), потребляемых за час. Убеждают, что алгоритм этого WAC - не хухры-мухры, а patent pending.

Этот WAC - это шестимерная сущность, представляющая собой эталонную совокупность ресурсов, потребляемых виртуальной машиной в облаке, а именно:

Вот в количестве таких шестигранных кубиков вы и увидите каждую из виртуальных машин своего (или провайдерского) датацентра в реальном времени. Предполагается, что такая модель позволит наиболее адекватно обсчитать вычислительные мощности своего ЦОД (chargeback), вести учет и планировать вычислительные мощности. Облачные провайдеры и менеджеры корпоративных датацентров могут устанавливать параметры и цену такого "вака", что позволит понимать, сколько ресурсов есть в наличии и сколько будет стоить разместить то или иное приложение в облаке.

Для каждой машины ведется исторический учет потребляемых "вакочасов":

Авторы этой программулины утверждают, что алгоритм этих "ваков" был разработан еще в 2004 году для профилирования приложений под ESX 1.0, так что может стоит и посмотреть, что они с тех пор сделали, тем более, что есть бесплатная версия продукта Cloud Resource Meter. На данный момент он, правда, находится в бете, но поддерживает vSphere 4.1 и 5.0.

Как известно, многие консольные команды старой сервисной консоли VMware ESX (например, esxcfg-*) в ESXi 5.0 были заменены командами утилиты esxcli, с помощью которой можно контролировать весьма широкий спектр настроек, не все из которых дублируются графическим интерфейсом vSphere Client. В списке ниже приведены некоторые полезные команды esxcli в ESXi 5.0, которыми можно воспользоваться в локальной консоли (DCUI) или по SSH для получения полезной информации как о самом хост-сервере, так и об окружении в целом.

1. Список nfs-монтирований на хосте:
# esxcli storage nfs list

2. Список установленных vib-пакетов:
# esxcli software vib list

3. Информация о памяти на хосте ESXi, включая объем RAM:
# esxcli hardware memory get

4. Информация о количестве процессоров на хосте ESXi:
# esxcli hardware cpu list

5. Список iSCSI-адаптеров и их имена:
# esxli iscsi adapter list

6. Список сетевых адаптеров:
# esxcli network nic list

7. Информация об IP-интерфейсах хоста:
# esxcli network ip interface list

8. Информация о настройках DNS:
# esxcli network ip dns search list
# esxcli network ip dns server list

9. Состояние активных соединений (аналог netstat):
# esxcli network ip connection list

10. Вывод ARP-таблицы:
# network neighbors list

11. Состояние фаервола ESXi и активные разрешения для портов и сервисов:
# esxcli network firewall get
# esxcli network firewall ruleset list

12. Информация о томах VMFS, подключенных к хосту:
# esxcli storage vmfs extent list

13. Мапинг VMFS-томов к устройствам:
# esxcli storage filesystem list

14. Текущая версия ESXi:
# esxcli system version get

15. Вывод информации о путях и устройствах FC:
# esxcli storage core path list
# esxcli storage core device list

16. Список плагинов NMP, загруженных в систему:
# esxcli storage core plugin list

17. Рескан HBA-адаптеров:
# esxcli storage core adapter rescan

18. Получить список ВМ с их World ID и убить их по этому ID (помогает от зависших и не отвечающих в vSphere Client ВМ):
# esxcli vm process list (получаем ID)
# esxcli vm process kill --type=[soft,hard,force] --world-id=WorldID (убиваем разными способами)

19. Узнать и изменить приветственное сообщение ESXi:
# esxcli system welcomemsg get
# esxcli system welcomemsg set

20. Поискать что-нибудь в Advanced Settings хоста:
# esxcli system settings advanced list | grep <var>

21. Текущее аппаратное время хоста:
# esxcli hardware clock get

22. Порядок загрузки с устройств:
# esxcli hardware bootdevice list

23. Список PCI-устройств:
# esxcli hardware pci list

24. Рескан iSCSI-адаптеров (выполняем две команды последовательно):
# esxcli iscsi adapter discovery rediscover -A <adapter_name>
# esxcli storage core adapter rescan [-A <adapter_name> | -all]

25. Список виртуальных коммутаторов и портгрупп:
# esxcli network vswitch standard list

Из основного вроде все. Если что-то еще используете - пиши плз в каменты. Полный список того, что можно сделать с esxcli, приведен в документе "Command-Line Management in vSphere 5.0
for Service Console Users".

Для тех из вас, кто умеет и любит разрабатывать скрипты на PowerCLI / PowerShell для виртуальной инфраструктуры VMware vSphere, приятная новость - вышло два полезных справочика в формате Quick Reference. Первый - vSphere 5.0 Image Builder PowerCLI Quick-Reference v0.2, описывающий основные командлеты для подготовки образов хост-серверов к автоматизированному развертыванию (а также собственных сборок ESXi) средствами Image Builder:

Второй - vSphere 5.0 AutoDeploy PowerCLI Quick-Reference v0.2, описывающий основные командлеты для автоматизации процесса развертывания хост-серверов ESXi средствами Auto Deploy:

Мы уже некоторое время назад писали про различные особенности томов VMFS, где вскользь касались проблемы блокировок в этой кластерной файловой системе. Как известно, в платформе VMware vSphere 5 реализована файловая система VMFS 5, которая от версии к версии приобретает новые возможности.

При этом в VMFS есть несколько видов блокировок, которые мы рассмотрим ниже. Блокировки на томах VMFS можно условно разделить на 2 типа:

• Блокировки файлов виртуальных машин
• Блокировки тома

Блокировки файлов виртуальных машин

Эти блокировки необходимы для того, чтобы файлами виртуальной машины мог в эксклюзивном режиме пользоваться только один хост VMware ESXi, который их исполняет, а остальные хосты могли запускать их только тогда, когда этот хост вышел из строя. Назвается этот механизм Distributed Lock Handling.

Блокировки важны, во-первых, чтобы одну виртуальную машину нельзя было запустить одновременно с двух хостов, а, во-вторых, для их обработки механизмом VMware HA при отказе хоста. Для этого на томе VMFS существует так называемый Heartbeat-регион, который хранит в себе информацию о полученных хостами блокировок для файлов виртуальных машин.

Обработка лока на файлы ВМ происходит следующим образом:

• Хосты VMware ESXi монтируют к себе том VMFS.
• Хосты помещают свои ID в специальный heartbeat-регион на томе VMFS.
• ESXi-хост А создает VMFS lock в heartbeat-регионе тома для виртуального диска VMDK, о чем делается соответствующая запись для соответствующего ID ESXi.
• Временная метка лока (timestamp) обновляется этим хостом каждые 3 секунды.
• Если какой-нибудь другой хост ESXi хочет обратиться к VMDK-диску, он проверяет наличие блокировки для него в heartbeat-регионе. Если в течение 15 секунд (~5 проверок) ESXi-хост А не обновил timestamp - хосты считают, что хост А более недоступен и блокировка считается неактуальной. Если же блокировка еще актуальна - другие хосты снимать ее не будут.
• Если произошел сбой ESXi-хоста А, механизм VMware HA решает, какой хост будет восстанавливать данную виртуальную машину, и выбирает хост Б.
• Далее все остальные хосты ESXi виртуальной инфраструктуры ждут, пока хост Б снимет старую и поставит свою новую блокировку, а также накатит журнал VMFS.

Данный тип блокировок почти не влияет на производительность хранилища, так как происходят они в нормально функционирующей виртуальной среде достаточно редко. Однако сам процесс создания блокировки на файл виртуальной машины вызывает второй тип блокировки - лок тома VMFS.

Блокировки на уровне тома VMFS

Этот тип блокировок необходим для того, чтобы хост-серверы ESXi имели возможность вносить изменения в метаданные тома VMFS, обновление которых наступает в следующих случаях:

• Создание, расширение (например, "тонкий" диск) или блокировка файла виртуальной машины
• Изменение атрибутов файла на томе VMFS
• Включение и выключение виртуальной машины
• Создание, расширение или удаление тома VMFS
• Создание шаблона виртуальной машины
• Развертывание ВМ из шаблона
• Миграция виртуальной машины средствами vMotion

Для реализации блокировок на уровне тома есть также 2 механизма:

• Механизм SCSI reservations - когда хост блокирует LUN, резервируя его для себя целиком, для создания себе эксклюзивной возможности внесения изменений в метаданные тома.
• Механизм "Hardware Assisted Locking", который блокирует только определенные блоки на устройстве (на уровне секторов устройства).

Наглядно механизм блокировок средствами SCSI reservations можно представить так:

Эта картинка может ввести в заблуждение представленной последовательностью операций. На самом деле, все происходит не совсем так. Том, залоченный ESXi-хостом А, оказывается недоступным другим хостам только на период создания SCSI reservation. После того, как этот reservation создан и лок получен, происходит обновление метаданных тома (более длительная операция по сравнению с самим резервированием) - но в это время SCSI reservation уже очищен, так как лок хостом А уже получен. Поэтому в процессе самого обновления метаданных хостом А все остальные хосты продолжают операции ввода-вывода, не связанные с блокировками.

Надо сказать, что компания VMware с выпуском каждой новой версии платформы vSphere вносит улучшения в механизм блокировки, о чем мы уже писали тут. Например, функция Optimistic Locking, появившаяся еще для ESX 3.5, позволяет собирать блокировки в пачки, максимально откладывая их применение, а потом создавать один SCSI reservation для целого набора локов, чтобы внести измененения в метаданные тома VMFS.

С появлением версии файловой системы VMFS 3.46 в vSphere 4.1 появилась поддержка функций VAAI, реализуемых производителями дисковых массивов, так называемый Hardware Assisted Locking. В частности, один из алгоритмов VAAI, отвечающий за блокировки, называется VAAI ATS (Atomic Test & Set). Он заменяет собой традиционный механизм SCSI reservations, позволяя блокировать только те блоки метаданных на уровне секторов устройства, изменение которых в эксклюзивном режиме требуется хостом. Действует он для всех перечисленных выше операций (лок на файлы ВМ, vMotion и т.п.).

Если дисковый массив поддерживает ATS, то традиционная последовательность SCSI-комманд RESERVE, READ, WRITE, RELEASE заменяется на SCSI-запрос read-modify-write для нужных блокировке блоков области метаданных, что не вызывает "замораживания" LUN для остальных хостов. Но одновременно метаданные тома VMFS, естественно, может обновлять только один хост. Все это лучшим образом влияет на производительность операций ввода-вывода и уменьшает количество конфликтов SCSI reservations, возникающих в традиционной модели.

По умолчанию VMFS 5 использует модель блокировок ATS для устройств, которые поддерживают этот механизм VAAI. Но бывает такое, что по какой-либо причине, устройство перестало поддерживать VAAI (например, вы откатили обновление прошивки). В этом случае обработку блокировок средствами ATS для устройства нужно отменить. Делается это с помощью утилиты vmkfstools:

vmkfstools --configATSOnly 0 device

где device - это пусть к устройству VMFS вроде следующего:

/vmfs/devices/disks/disk_ID:P

Продолжаем рассказывать технические подробности о сертифицированном ФСТЭК продукте vGate R2, который предназначен для обеспечения безопасности виртуальной инфраструктуры VMware vSphere (в том числе 5-й версии) средствами политик ИБ и механизма защиты от НСД.

Сегодня мы поговорим о компоненте защиты сервера vCenter, который входит в поставку vGate R2. Это сетевой экран, который позволит вам дополнить решение по защите виртуальной среды VMware vSphere. В его установке нет никаких сложностей - ставится он методом "Next->Next->Next":

Потребуется лишь указать параметры базы сервера авторизации, который должен быть развернут в виртуальной среде (как это делается - тут) и параметры внешней подсети, в которую смотрит сервер vCenter (это сеть, откуда соединяются через клиент vSphere администраторы виртуальной инфраструктуры):

После этого компонент vGate R2 для защиты vCenter будет установлен. У него нет графического интерфейса, поэтому для задания правил сетевого экрана нужно воспользоваться консольной утилитой. Компонент защиты, устанавливаемый на vCenter, осуществляет фильтрацию только входящего трафика. При этом разрешены только штатные входящие сетевые соединения:

• соединения из внешнего периметра сети администрирования через сервер
  авторизации
• доступ с сервера авторизации на TCP-порт 443 и по протоколу ICMP
• доступ на UDP-порт 902 c ESX-серверов

Если необходимо разрешить доступ к vCenter с какого-либо иного направления, то необходимо добавить правила доступа с помощью специальной утилиты командной строки drvmgr.exe.

Описание некоторых команд утилиты drvmgr.exe и их параметров приведено ниже:

• > drvmgr
  Вызов справки
• > drvmgr i 0x031
  Просмотр текущих правил фильтрации
• >drvmgr А protocol IP_from[:source_port[,mask]] [:destination_port] [Flags]
  Добавление правила фильтрации
• >drvmgr R protocol IP_from[:source_port[,mask]] [destination_port] [Flags]
  Удаление правила фильтрации

Описание аргументов параметров команд утилиты приведено в таблице:

Например, для добавления правила, разрешающего входящие соединения из сети 172.28.36.0 по любому протоколу на любой входящий порт vСenter, формат команды следующий:

>drvmgr A any 172.28.36.0:any,255.255.255.0 any 4

Для удаления вышеуказанного правила следует указать команду:

>drvmgr R any 172.28.36.0:any,255.255.255.0 any 4

Скачать пробную версию продукта vGate R2 можно по этой ссылке. Презентации по защите виртуальных инфраструктур доступны тут, а сертификаты ФСТЭК продукта - здесь.

Мы уже писали о продукте для комплексного мониторинга и управления виртуальной инфраструктурой VMware vCenter Operations Management Suite, в состав которого входит ПО для отслеживания взаимосвязей на уровне приложений VMware vCenter Infrastructure Navigator. На днях компания VMware выпустила обновление - VMware vCenter Infrastructure Navigator 1.1.

Напомним, что Infrastructure Navigator - это плагин к vCenter (интегрируется в веб-клиент VMware vSphere 5 Web Client), поставляемый в виде виртуального модуля (Virtual Appliance), который строит структуру взаимосвязей на уровне приложений в виртуальных машинах, что позволяет анализировать завимости уровня приложений и их связ с объектами VMware vSphere.

vCenter Infrastructure Navigator предоставляет следующие основные возможности:

• Построение карты сервисов в виртуальной среде для того, чтобы отследить взаимосвязь проблемы отдельного сервиса и виртуальной инфраструктуры. Приложения в виртуальных машинах и взаимосвязи между ними обнаруживаются и добавляются на карту автоматически.
• Отслеживание влияния изменений в приложениях на группы сервисов и виртуальную среду в целом для дальнейшего анализа влияния на бизнес-функции виртуальной инфраструктуры.
• Ассоциирование объектов виртуальной инфраструктуры с объектами приложений, что позволяет оперировать с объектами vSphere, относящимися к конкретному сервису (например, поиск ВМ, реализующих сервисы Exchange и управление ими).
• Поддержка взаимосвязей на уровне приложений для корректного восстановления инфраструктуры на DR-площадке (например, с помощью VMware SRM)

Если обобщить, то vCenter Infrastructure Navigator позволяет отобразить линейный список ваших виртуальных машин в vSphere Client на карту зависимостей сервисов друг от друга (с учетом портов взаимодействия), что позволит понять влияние тех или иных действий с виртуальной машиной или приложением в ней на другие составляющие ИТ-инфраструктуры компании:

То есть, слева у вас просто список машин (в данном случае, в контейнере vApp), а справа - уже карта связей на уровне компонентов приложений.

Новые возможности VMware vCenter Infrastructure Navigator 1.1:

• Поддержка продукта VMware vCloud Director (VCD) для облачных сред.
• Поддержка внешних взаимосвязей для приложений. Например, сервисов виртуальной машины с сервисами физического сервера, который не управляется vCenter.
• Обнаружение неизвестных сервисов - для них просто указывается тип "unknown", имя процесса и порт, на котором сервис слушает.
• Возможность задания пользовательского типа сервиса на базе атрибутов: имя процесса, порт.
• Поддержка обнаружения следующих сервисов: Site Recovery Manager (SRM) Server, VMware View Server, VMware vCloud Director Server и VMware vShield Manager Server.
• Нотификации о различных ошибках на отдельной панели.
• Возможность раскрытия объектов карты сервисов из одного представления для вывода необходимого уровня детальности дерева взаимосвязей.

Напоминаем, что VMware vCenter Infrastructure Navigator 1.1 является частью продукта VMware vCenter Operations Management Suite и доступен для загрузки по этой ссылке. Также обновился и сам VMware vCenter Operations Manager (основная часть Suite) до версии 5.01.

Сотрудники компании VMware не так давно на корпоративном блоге публиковали заметки о сравнении протоколов FC, iSCSI, NFS и FCoE, которые используются в VMware vSphere для работы с хранилищами. В итоге эта инициатива переросла в документ "Storage Protocol Comparison", который представляет собой сравнительную таблицу по различным категориям, где в четырех столбиках приведены преимущества и особенности того или иного протокола:

Полезная штука со многими познавательными моментами.

Одним из ключевых нововведений VMware vSphere 5, безусловно, стала технология выравнивания нагрузки на хранилища VMware vSphere Storage DRS (SDRS), которая позволяет оптимизировать нагрузку виртуальных машин на дисковые устройства без прерывания работы ВМ средствами технологии Storage vMotion, а также учитывать характеристики хранилищ при их первоначальном размещении.

Основными функциями Storage DRS являются:

• Балансировка виртуальных машин между хранилищами по вводу-выводу (I/O)
• Балансировка виртуальных машин между хранилищами по их заполненности
• Интеллектуальное первичное размещение виртуальных машин на Datastore в целях равномерного распределения пространства
• Учет правил существования виртуальных дисков и виртуальных машин на хранилищах (affinity и anti-affinity rules)

Ключевыми понятими Storage DRS и функции Profile Driven Storage являются:

• Datastore Cluster - кластер виртуальных хранилищ (томов VMFS или NFS-хранилищ), являющийся логической сущностью в пределах которой происходит балансировка. Эта сущность в чем-то похожа на обычный DRS-кластер, который составляется из хост-серверов ESXi.
• Storage Profile - профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Необходимы эти профили для того, чтобы виртуальные машины с различным уровнем обслуживания по вводу-выводу (или их отдельные диски) всегда оказывались на хранилищах с требуемыми характеристиками производительности.

При создании Datastore Cluster администратор указывает, какие хранилища будут в него входить (максимально - 32 штуки в одном кластере):

Как и VMware DRS, Storage DRS может работать как в ручном, так и в автоматическом режиме. То есть Storage DRS может генерировать рекомендации и автоматически применять их, а может оставить их применение на усмотрение пользователя, что зависит от настройки Automation Level.

С точки зрения балансировки по вводу-выводу Storage DRS учитывает параметр I/O Latency, то есть round trip-время прохождения SCSI-команд от виртуальных машин к хранилищу. Вторым значимым параметром является заполненность Datastore (Utilized Space):

Параметр I/O Latency, который вы планируете задавать, зависит от типа дисков, которые вы используете в кластере хранилищ, и инфраструктуры хранения в целом. Однако есть некоторые пороговые значения по Latency, на которые можно ориентироваться:

• SSD-диски: 10-15 миллисекунд
• Диски Fibre Channel и SAS: 20-40 миллисекунд
• SATA-диски: 30-50 миллисекунд

По умолчанию рекомендации по I/O Latency для виртуальных машин обновляются каждые 8 часов с учетом истории нагрузки на хранилища. Также как и DRS, Storage DRS имеет степень агрессивности: если ставите агрессивный уровень - миграции будут чаще, консервативный - реже. Первой галкой "Enable I/O metric for SDRS recommendations" можно отключить генерацию и выполнение рекомендаций, которые основаны на I/O Latency, и оставить только балансировку по заполненности хранилищ.

То есть, проще говоря, SDRS может переместить в горячем режиме диск или всю виртуальную машину при наличии большого I/O Latency или высокой степени заполненности хранилища на альтернативный Datastore.

Самый простой способ - это балансировка между хранилищами в кластере на базе их заполненности, чтобы не ломать голову с производительностью, когда она находится на приемлемом уровне.

Администратор может просматривать и применять предлагаемые рекомендации Storage DRS из специального окна:

Когда администратор нажмет кнопку "Apply Recommendations" виртуальные машины за счет Storage vMotion поедут на другие хранилища кластера, в соответствии с определенным для нее профилем (об этом ниже).

Аналогичным образом работает и первичное размещение виртуальной машины при ее создании. Администратор определяет Datastore Cluster, в который ее поместить, а Storage DRS сама решает, на какой именно Datastore в кластере ее поместить (основываясь также на их Latency и заполненности).

При этом, при первичном размещении может случиться ситуация, когда машину поместить некуда, но возможно подвигать уже находящиеся на хранилищах машины между ними, что освободит место для новой машины (об этом подробнее тут):

Как видно из картинки с выбором кластера хранилищ для новой ВМ, кроме Datastore Cluster, администратор первоначально выбирает профиль хранилищ (Storage Profile), который определяет, по сути, уровень производительности виртуальной машины. Это условное деление хранилищ, которое администратор задает для хранилищ, обладающих разными характеристиками производительности. Например, хранилища на SSD-дисках можно объединить в профиль "Gold", Fibre Channel диски - в профиль "Silver", а остальные хранилища - в профиль "Bronze". Таким образом вы реализуете концепцию ярусного хранения данных виртуальных машин:

Выбирая Storage Profile, администратор будет всегда уверен, что виртуальная машина попадет на тот Datastore в рамках выбранного кластера хранилищ, который создан поверх дисковых устройств с требуемой производительностью. Профиль хранилищ создается в отельном интерфейсе VM Storage Profiles, где выбираются хранилища, предоставляющие определенный набор характеристик (уровень RAID, тип и т.п.), которые платформа vSphere получает через механизм VASA (VMware vStorage APIs for Storage Awareness):

Ну а дальше при создании ВМ администратор определяет уровень обслуживания и характеристики хранилища (Storage Profile), а также кластер хранилища, датасторы которого удовлетворяют требованиям профиля (они отображаются как Compatible) или не удовлетворяют им (Incompatible). Концепция, я думаю, понятна.

Регулируются профили хранилищ для виртуальной машины в ее настройках, на вкладке "Profiles", где можно их настраивать на уровне отдельных дисков:

На вкладке "Summary" для виртуальной машины вы можете увидеть ее текущий профиль и соответствует ли в данный момент она его требованиям:

Также можно из оснастки управления профилями посмотреть, все ли виртуальные машины находятся на тех хранилищах, профиль которых совпадает с их профилем:

Далее - правила размещения виртуальных машин и их дисков. Определяются они в рамках кластера хранилищ. Есть 3 типа таких правил:

• Все виртуальные диски машины держать на одном хранилище (Intra-VM affinity) - установлено по умолчанию.
• Держать виртуальные диски обязательно на разных хранилищах (VMDK anti-affinity) - например, чтобы отделить логи БД и диски данных. При этом такие диски можно сопоставить с различными профилями хранилищ (логи - на Bronze, данны - на Gold).
• Держать виртуальные машины на разных хранилищах (VM anti-affinity). Подойдет, например, для разнесения основной и резервной системы в целях отказоустойчивости.

Естественно, у Storage DRS есть и свои ограничения. Основные из них приведены на картинке ниже:

Основной важный момент - будьте осторожны со всякими фичами дискового массива, не все из которых могут поддерживаться Storage DRS.

И последнее. Технологии VMware DRS и VMware Storage DRS абсолютно и полностью соместимы, их можно использовать совместно.

Мы уже писали о возможностях настольной платформы виртуализации VMware Workstation 8, а также функционале, который нас ожидает в Workstation 2012. Раньше, когда еще существовал VMware Server, многие небольшие компании использовали именно его, поскольку он был прост и бесплатен, а что важнее - не требовал специфического "железа". Даже когда вышел бесплатный VMware ESXi (сейчас он, напомним, называется vSphere Hypervisor), многие по-прежнему использовали VMware Server, где не требовалось никаких особенных навыков администрирования, в отличие от ESXi.

А потом VMware Server не стало, и пользователи в маленьких компаниях, которые не могут позволить купить себе нормальные серверы и хранилища, остались ни с чем. Приходилось покупать Whitebox'ы для ESXi или использовать VMware Workstation. Так вот специально для таких пользователей в восьмой версии Workstation появились "серверные" функции, реализующе "общие виртуальные машины", описание которых можно увидеть на видео ниже:

Также в VMware Workstation 8 есть возможность автостарта виртуальных машин при старте компьютера, который раньше приходилось реализовывать самостоятельно. С шарингом виртуальных машин все просто - вы назначаете привилегии на виртуальные машины пользователям, а в консоли Workstation они появляются в категории Shared VMs. Панель так и озаглавлена: VMware Workstation Server:

Правда при таком их использовании теряются следующие функции:

• Unity
• Shared Folders
• AutoProtect
• Drag and drop
• Copy and paste

Но, надо сказать, что серверам они не особенно-то и нужны. Такая модель использования VMware Workstation пригодиться рабочим группам и в крупных компаниях, которым не требуются возможности производственного датацентра компании, в первую очередь разработчикам и тестировщикам.

Rob de Veij, выпускающий бесплатную утилиту для настройки и аудита виртуальной инфраструктуры VMware vSphere (о ней мы не раз писали), выпусил обновление RVTools 3.3. Кстати, со времен выпуска версии 3.0, RVTools научилась поддерживать ESXi 5.0 и vCenter 5.0.

Новые возможности RVTools 3.3:

• Таймаут GetWebResponse увеличен с 5 минут до 10
• Новая вкладка с информацией о HBA-адаптерах (на картинке выше)
• Приведена в порядок вкладка vDatastore
• Функция отсылки уведомлений по почте RVToolsSendMail поддерживает несколько получателей через запятую
• Информация о папке VMs and Templates показывается на вкладке vInfo
• Несколько исправлений багов

Скачать полезную и бесплатную RVTools 3.3 можно по этой ссылке. Что можно увидеть на вкладках описано здесь.

В преддверии выхода новой версии платформы для виртуализации настольных ПК VMware View 5.1, о котором будет объявлено 3 мая, продолжаем рассказывать о новых возможностях этого продукта. Сегодня продолжим разговор о функции Content Based Read Cache (CBRC), которая позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК.

Как мы уже писали ранее, Content Based Read Cache - это функция кэширования в оперативной памяти хоста VMware ESXi, которая уже реализована в VMware vSphere 5. Убедиться в этом вы можете сами, открыв Advanced Settings на хосте:

Как мы видим из картинки, есть планка для CBRC размером в 2 ГБ, которую нельзя менять и есть текущее значение памяти, зарезервированной для кэша. Кроме того, есть настройка таймаута при загрузке хоста для дайджест-журнала SCSI, который хранит в себе хэш-таблицу блоков, которые учитывает кэш CBRC при их запросе от виртуальной машины.

Этот дайджест хранится в папке с виртуальной машиной в виде отдельного VMDK-файла:

То есть, при чтении виртуальной машиной блока с хранилища, он сначала ищется в кэше, и, если он там отсутствует, то он туда помещается и отдается виртуальной машине. Ну а если он в кэше есть - то сразу ей отдается. Соответственно, кэш CBRC увеличивает производительность при операциях чтения виртуальных машин хоста с одними и теми же блоками, что часто бывает в инфраструктуре VDI. Особенно это актуально при одновременной загрузке десятков виртуальных ПК, которая может вызвать так называемый Boot Storm. Посмотрите, как увеличивается интенсивность операций чтения при загрузке Windows ВМ, с которую может существенно "погасить" CBRC:

Надо отметить, что CBRC - это чисто хостовая фишка VMware vSphere, которую может поддерживать любое надстроенное VDI-решение (например, Citrix XenDesktop). А вот в VMware View поддержка CBRC будет идти под эгидой функции VMware View Storage Accelerator:

Как понятно из описанного выше, для такой поддержки практически ничего уже и делать не нужно - все есть в ESXi 5.0.

Во второй части заметки рассмотрим возможность VMware View Client Side Caching, которая представляет собой использование кэша в оперативной памяти устройств доступа к виртуальным ПК (тонкие и толстые клиенты с View Client) для картинки рабочего стола (а точнее, ее регионов). Эта возможность появилась уже в VMware View 5.0 и включена по умолчанию: 250 МБ памяти используется на клиенте, за исключением всяких Android и iOS-устройств.

Представьте, что вы просматриваете в виртуальном ПК PDF-документ. Рамка и контролы в ридере остаются на месте, а его содержимое скроллится в ограниченной области экрана. Вот для этого и нужен Client Side Caching - он позволяет закэшировать этот неизменяющийся фрагмент картинки экрана и не обращаться за ним к хосту и хранилищу. Это увеличивает производительность виртуального ПК до 30%.

Настраивается это просто - через шаблон групповой политики pcoip.adm, про работу с которым написано, например, вот тут. Настройка GPO называется "Configure PCoIP client image cache size policy":

Диапазон допустимых значений - от 50 до 300 МБ. Работает эта штука и для Linux-устройств. С ней есть тоже одна засада - если на тонком клиенте мало оперативной памяти (меньше 1 ГБ), клиентский кэш луше немного уменьшить, если наблюдаются проблемы с производительностью.

Мы уже не раз писали о продукте номер 1 - vGate R2, который является лидером на рынке защиты виртуальных инфраструктур за счет средств автоматической настройки виртуальной среды VMware vSphere и механизмов защиты от несанкционированного доступа. Сегодня мы поговорим о резервировании сервера авторизации vGate R2. Сервер авторизации - это основной компонент vGate R2, который осуществляет авторизацию и аутентификацию пользователей, без которого нельзя будет администрировать среду VMware vSphere, если он вдруг выйдет из строя. Он выполняет следующие функции...

Мы уже писали о том, как сбросить пароль root на VMware ESX версии 4.0 и 4.1 в случае, если вы забыли его (тут для single user mode). Теперь появилась еще одна инструкция от Бернарда, которая аналогична предыдущей от Дэйва и работает для VMware ESXi 5.0. Перед тем, как сбросить пароль на VMware ESXi, надо понимать, что приведенная ниже инструкция может привести к неподдерживаемой со стороны VMware конфигурации, о чем прямо написано в KB 1317898.

Итак восстановление пароля на хосте ESXi 5.0:

1. Хэш пароля хранится в файле etc/shadow, который хранится в архиве local.tgz, который хранится в архиве state.tgz:

2. Загружаем сервер ESXi с какого-нибудь Live CD (например, GRML), используя CD/DVD или USB-флешку.

3. После загрузки находим и монтируем раздел VFAT инсталляции ESXi, содержащий файл state.tgz. Например, он может быть на разделе Hypervisor3:

mount /mnt/Hypervisor3

Ищем как написано тут.

4. Распаковываем state.tgz куда-нибудь:

cd /tmp
tar xzf /mnt/Hypervisor3/state.tgz

5. Затем распаковываем local.tgz:

tar xzf local.tgz

6. В результате распаковки получим директорию /etc, в которой есть файл shadow. Открываем его в vi для редактирования:

vi etc/shadow

Удаляем хэш пароля root (до двоеточия перед цифрами). Было:

Стало:

7. Сохраняем резервную копию state.tgz и перепаковываем архив:

mv /mnt/Hypervisor3/state.tgz /mnt/Hypervisor3/state.tgz.bak
rm local.tgz
tar czf local.tgz etc
tar czf state.tgz local.tgz
mv state.tgz /mnt/Hypervisor3/

8. Перезагружаем сервер и уже загружаемся в VMware ESXi 5.0. Видим такую картинку при соединении из vSphere Client:

Это значит, что все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Работает эта штука и для VMware ESXi 5.0 Upfate 1.

Как известно, компания VMware уже довольно давно выпускает руководство по обеспечению информационной безопасности VMware vSphere Security Hardening Guide (тут и тут), содержащее список потенциальных угроз ИБ и их возможное влияние на инфраструктуру виртуализации. Также доступен Security Hardening Guide для VMware View и vCloud Director.

Вчера компания VMware выпустила черновую версию VMware vSphere 5 Security Hardening Guide, которая традиционно рассматривает угрозы в следующих сферах:

• Виртуальные машины (настройки, устройства, интерфейсы, VMware Tools)
• Хосты VMware ESXi (доступ к управлению, логи, хранилища)
• Сетевое взаимодействие (включая распределенный коммутатор dvSwitch)
• Сервер управления vCenter (доступ к управляющим компонентам и т.п.)

На данный момент руководство доступно в виде xlsx-табличек:

Основная страница обсуждения документа находится здесь.

Кроме того, вчера же появился и документ "vSphere Hardening Guide: 4.1 and 5.0 comparison", отражающий основные отличия руководства для версий 4.1 и 5.0. Там хорошо видно, какие новые фичи vSphere 5 покрывает новая версия документа:

Соответственно, можно ожидать скорого появления обновленных версий продуктов vGate R2 и vGate Compliance Checker, позволяющих проверить соответствия вашей инфраструктуры нормам данного руководящего документа и настроить виртуальную инфраструктуру VMware vSphere в соответствии с ними средствами политик.